Fix CLI handshake on Windows named pipes with newline framing - #31

Problem

On Windows, every dapi command that connects to the desktop app fails with:

Unexpected end of JSON input

The CLI handshake frames its messages by half-closing the socket:

• the client (apps/cli/src/cli-client.ts) writes the handshake JSON, calls sock.end(), and parses the reply on 'end';
• the server (apps/desktop/src/cli-server.ts) buffers until 'end', then handles the handshake and replies.

On Unix domain sockets this works because the connection stays half-open after end(). Windows named pipes (\\.\pipe\diffusion-studio) do not support half-open connections: the client's end() tears the whole pipe down, the reply never arrives, and the client parses an empty buffer.

Fix

Switch the handshake to newline framing, keeping the old half-close path working:

• Client: write JSON + "\n" without half-closing, and resolve as soon as a newline-terminated reply arrives. If the peer closes without a trailing newline (an older server on Unix), fall back to parsing the buffered data on 'end' as before.
• Server: handle the handshake as soon as the first newline arrives, and terminate replies with "\n". Clients that still frame by half-closing are handled on 'end' as before.

So new and old peers interoperate in both directions on Unix, and on Windows — where both sides ship together (app + bundled CLI) — the handshake now completes.

Testing

• Windows 11 (10.0.26200), Node v22.23.1: before this change, dapi mount <file> (or any command that connects to the app) always failed with Unexpected end of JSON input; with it, the full mount → node capture → node render flow works against a real project.
• npm run check (tsc --noEmit) passes in apps/desktop; apps/cli bundles cleanly with esbuild.

Notes

There are a couple of further Windows papercuts in the dev tooling (scripts/dev-desktop.mjs spawnSync npm ENOENT, chmod in the CLI build script) — reported separately in #30 since they're independent of this fix.

🤖 Generated with Claude Code